Skip to main content

Introduction

DIDs are URIs associated with a subject and, together with a DID Document, enable trustworthy interactions associated with that subject. They are designed to give to the controller of a DID full control over it without requiring permission from any other party. They are decentralized and interoperable identifiers that were created to unlink themselves from centralized identifiers.

Did Scheme

Did Document​

These DIDs resolve a DID DOCUMENT, which is an element associated with a DID, through which we can obtain information about it and thus communicate with that DID. Therefore, the DID document only contains information to communicate with the outside world; it should not contain data that identifies the subject of the DID.

The previous DID resolves the following DID Document.

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  "authentication": [{
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
}

Example of a did document obtained from W3C

Verification method and Verification relationship​

What will allow us to communicate with that DID will be found within the verification methods of the DID document.

It is necessary to differentiate between what a verification method and a verification relationship are.

On one hand, we must understand that verification methods are composed of public keys known through the DID document, enabling communication with that DID.

These public keys serve us for signature verification, but they are also permissioned, and we call those permissions verification relationships, which describe the reason for which we want to use a particular public key.

In the example DID document, what we see under "authentication" are the keys used for authentication. In this case, we can observe that within the same verification relationship, we have the verification method, but it is not always represented this way. It is possible to encounter DID documents where the verification methods are separated and decoupled from the verification relationships.

Therefore, verification relationships are those that define what we can use a key for.

In other words, a verification method is a public key through which someone can communicate with that DID by signing with their private key, generating a shared key between both parties. The receiver can decrypt that message with their private key, knowing the sender's public key through their DID document.

Example​

In the example below, we can observe a DID document in which the verification methods are completely decoupled from the verification relationships, which have sections according to their purpose, referring to keys by their ID.

In this particular case, we see some verification relationships used for authentication, issuing a credential, or for communication with another DID.

Did Document